프론트엔드 Performance Observer 사용자 지정 메트릭: 애플리케이션별 측정

웹 개발 세계에서 최적의 프론트엔드 성능을 보장하는 것은 매우 중요합니다. 브라우저는 다양한 성능 메트릭을 제공하지만, 종종 애플리케이션별 동작을 포착하는 데는 부족합니다. 바로 이 지점에서 Frontend Performance Observer API와 사용자 지정 메트릭을 정의하는 기능이 매우 유용해집니다. 이 글에서는 Performance Observer를 활용하여 맞춤형 메트릭을 추적하고, 애플리케이션의 성능 환경에 대한 맞춤형 뷰를 제공하는 과정을 안내합니다.

사용자 지정 메트릭의 필요성 이해하기

최초 콘텐츠풀 페인트(FCP), 최대 콘텐츠풀 페인트(LCP), 상호작용까지의 시간(TTI)과 같은 표준 브라우저 성능 메트릭은 페이지 로드 및 응답성에 대한 일반적인 개요를 제공합니다. 그러나 이러한 메트릭은 특정 애플리케이션 내의 사용자 경험을 정확하게 반영하지 못하는 경우가 많습니다. 다음 시나리오를 고려해 보세요:

• 전자상거래 애플리케이션: 장바구니에 상품을 추가하거나 결제 프로세스를 완료하는 데 걸리는 시간.
• 소셜 미디어 플랫폼: 사용자 피드를 로드하거나 업데이트를 게시하는 데 걸리는 지연 시간.
• 금융 대시보드: 복잡한 금융 데이터를 계산하고 표시하는 데 필요한 시간.
• 지도 애플리케이션: 지도 타일을 로드하거나 지리적 데이터를 렌더링하는 데 걸리는 지연 시간.

이러한 애플리케이션별 작업은 사용자 경험에 매우 중요하지만 표준 성능 메트릭으로는 직접 포착되지 않습니다. 사용자 지정 메트릭은 이 격차를 해소하여 중요한 기능의 성능을 모니터링하고 사용자 행동에 대한 더 깊은 이해를 얻을 수 있게 해줍니다.

Performance Observer API 소개

Performance Observer API는 브라우저에서 발생하는 성능 메트릭을 관찰하고 수집하는 메커니즘을 제공합니다. 이를 통해 `paint`, `resource`, `navigation` 및 가장 중요한 `measure`와 `mark`와 같은 특정 성능 항목 유형을 구독할 수 있습니다. 이러한 이벤트 기반 접근 방식을 통해 성능 이벤트에 실시간으로 반응하고 분석을 위한 데이터를 수집할 수 있습니다.

Performance Observer API의 핵심 구성 요소는 다음과 같습니다:

• `PerformanceObserver` 생성자: 새로운 PerformanceObserver 인스턴스를 생성합니다.
• `observe()` 메서드: 관찰할 성능 항목 유형을 지정합니다.
• `disconnect()` 메서드: 옵저버가 성능 항목을 수신하는 것을 중지합니다.
• `takeRecords()` 메서드: 마지막 호출 이후 버퍼에 저장된 모든 성능 항목을 반환합니다.

`mark`와 `measure`를 사용한 사용자 지정 메트릭 정의

`mark`와 `measure` API는 사용자 지정 성능 메트릭을 생성하는 데 기본이 됩니다. 작동 방식은 다음과 같습니다:

• `performance.mark(markName)`: 브라우저의 성능 타임라인에 타임스탬프가 찍힌 마커를 생성합니다. 측정하려는 특정 이벤트의 시작과 끝을 나타내는 데 `mark`를 사용합니다.
• `performance.measure(measureName, startMark, endMark)`: 두 마크 사이의 지속 시간을 계산하고 `measure` 유형의 성능 항목을 생성합니다. `measureName`은 사용자 지정 메트릭의 고유 식별자입니다.

예를 들어 설명해 보겠습니다. 사용자 상호작용 후 특정 컴포넌트가 렌더링되는 데 걸리는 시간을 측정하고 싶다고 가정해 봅시다.

            
// Start measuring the rendering process
performance.mark('componentRenderStart');

// ... (Component rendering logic here) ...

// End measuring the rendering process
performance.mark('componentRenderEnd');

// Create a measure to calculate the duration
performance.measure('componentRenderTime', 'componentRenderStart', 'componentRenderEnd');

            

              
                Copy
              
            
          

사용자 지정 메트릭을 위한 Performance Observer 구현하기

이제 `measure` 항목을 수신하고 사용자 지정 메트릭 데이터를 처리하기 위한 Performance Observer를 생성해 보겠습니다.

            
const observer = new PerformanceObserver((list) => {
  list.getEntriesByType('measure').forEach((entry) => {
    console.log(`Custom Metric: ${entry.name} - Duration: ${entry.duration}ms`);
    // In a real-world scenario, you would send this data to your analytics platform
    // Example:
    // trackCustomMetric(entry.name, entry.duration);
  });
});

observer.observe({ entryTypes: ['measure'] });

            

              
                Copy
              
            
          

이 코드 스니펫은 `measure` 항목을 수신하는 Performance Observer를 생성합니다. `measure` 항목이 생성되면(`performance.measure`를 통해) 옵저버의 콜백 함수가 실행됩니다. 콜백 함수는 수집된 항목을 반복하며 메트릭 이름과 지속 시간을 콘솔에 기록하고, 이상적으로는 추가 분석을 위해 데이터를 분석 플랫폼으로 전송합니다.

실용 예제: 실제 사용자 지정 메트릭 활용

사용자 지정 메트릭을 사용하여 애플리케이션 성능의 특정 측면을 모니터링하는 몇 가지 실용적인 예제를 살펴보겠습니다.

1. API 응답 시간 측정

백엔드 API로부터 응답을 받는 데 걸리는 시간을 추적하는 것은 잠재적인 병목 현상을 식별하는 데 매우 중요합니다. API 응답 시간을 측정하는 방법은 다음과 같습니다:

            
async function fetchData() {
  performance.mark('apiCallStart');
  const response = await fetch('/api/data');
  performance.mark('apiCallEnd');
  performance.measure('apiResponseTime', 'apiCallStart', 'apiCallEnd');
  return response.json();
}

            

              
                Copy
              
            
          

이 코드 스니펫은 `/api/data` 엔드포인트에서 데이터를 가져오는 데 걸리는 시간을 측정합니다. `apiResponseTime` 메트릭은 요청 시작부터 응답 수신까지의 API 호출 전체 기간을 포착합니다.

2. 이미지 로드 시간 추적

이미지는 종종 페이지 로드 성능에 중요한 요소입니다. 이미지가 로드되는 데 걸리는 시간을 측정하면 크기가 너무 큰 이미지나 느린 CDN을 식별하는 데 도움이 될 수 있습니다.

            
const image = new Image();
image.onload = () => {
  performance.mark('imageLoadEnd');
  performance.measure('imageLoadTime', 'imageLoadStart', 'imageLoadEnd');
};
performance.mark('imageLoadStart');
image.src = 'https://example.com/image.jpg';

            

              
                Copy
              
            
          

이 코드 스니펫은 지정된 URL에서 이미지를 로드하는 데 걸리는 시간을 측정합니다. `imageLoadTime` 메트릭은 이미지 요청 시작부터 이미지 로드 완료까지의 기간을 포착합니다.

3. 서드파티 스크립트 실행 시간 모니터링

서드파티 스크립트는 종종 프론트엔드 성능에 상당한 영향을 미칠 수 있습니다. 실행 시간을 측정하면 문제가 있는 스크립트를 식별하고 로딩 또는 실행을 최적화하는 데 도움이 될 수 있습니다.

            
// Assuming the third-party script has a global function called 'thirdPartyScript'

performance.mark('thirdPartyScriptStart');
thirdPartyScript();
performance.mark('thirdPartyScriptEnd');
performance.measure('thirdPartyScriptExecutionTime', 'thirdPartyScriptStart', 'thirdPartyScriptEnd');

            

              
                Copy
              
            
          

이 코드 스니펫은 가상의 서드파티 스크립트 실행 시간을 측정합니다. `thirdPartyScriptExecutionTime` 메트릭은 스크립트 실행 기간을 포착합니다.

4. 특정 컴포넌트의 상호작용까지의 시간(TTI) 측정

TTI는 표준 메트릭이지만, 특정 컴포넌트가 상호작용 가능해지는 데 걸리는 시간을 측정하도록 사용자 지정할 수 있습니다. 이를 통해 어떤 컴포넌트가 전체 TTI에 가장 많이 기여하는지 정확히 찾아낼 수 있습니다.

            
// After your component is fully rendered and interactive
performance.mark('componentInteractive');
performance.measure('componentTTI', 'componentRenderStart', 'componentInteractive');

            

              
                Copy
              
            
          

이 예제는 `componentRenderStart`가 이전에 정의되었다고 가정합니다. 컴포넌트 렌더링이 시작된 시점부터 완전히 상호작용 가능해진 시점까지의 시간을 측정합니다.

고급 기술 및 고려 사항

기본 사항 외에, Performance Observer와 사용자 지정 메트릭을 효과적으로 사용하기 위한 몇 가지 고급 기술 및 고려 사항은 다음과 같습니다:

1. 복잡한 시나리오를 위한 User Timing API 사용

더 복잡한 시나리오의 경우, 이벤트의 여러 단계를 추적하기 위해 여러 개의 마크와 측정 항목을 만들어야 할 수 있습니다. User Timing API는 이러한 마커와 계산을 관리하는 유연한 방법을 제공합니다.

2. Long Tasks API 활용

Long Tasks API는 메인 스레드를 장시간 차단하여 사용자 경험을 저해하는 작업을 식별하는 데 도움이 될 수 있습니다. 이를 사용자 지정 메트릭과 결합하여 긴 작업과 특정 애플리케이션 작업을 연관시킬 수 있습니다.

3. `buffered` 플래그 및 지연 로딩 옵저버

일부 성능 이벤트가 이미 발생한 후에 Performance Observer를 초기화하는 경우, `buffered` 플래그를 사용하여 해당 이벤트를 검색할 수 있습니다. 예:

            
const observer = new PerformanceObserver((list) => { /* ... */ });
observer.observe({ entryTypes: ['measure'], buffered: true });

            

              
                Copy
              
            
          

4. 스로틀링 및 디바운싱

빈도가 높은 시나리오에서는 성능 오버헤드를 피하기 위해 메트릭 수집을 스로틀링하거나 디바운싱하는 것을 고려하십시오. 예를 들어, 마우스 움직임을 추적하는 경우 100ms마다 데이터를 수집할 수 있습니다.

5. 데이터 집계 및 분석

Performance Observer가 수집한 원시 성능 데이터는 의미 있는 통찰력을 제공하기 위해 집계 및 분석되어야 합니다. 이는 일반적으로 Google Analytics, New Relic 또는 자체 구축 솔루션과 같은 분석 플랫폼으로 데이터를 전송하는 것을 포함합니다. 분석 플랫폼이 사용자 지정 메트릭을 처리하고 필요한 보고 기능을 제공할 수 있는지 확인하십시오.

6. 실제 사용자 모니터링 (RUM)

애플리케이션 성능의 실제 모습을 파악하려면 실제 사용자 모니터링(RUM)을 구현하십시오. RUM은 실제 사용자의 실제 환경에서 성능 데이터를 수집하여 다양한 사용자와 장치에서 애플리케이션이 어떻게 수행되는지에 대한 귀중한 통찰력을 제공합니다. 사용자 지정 메트릭은 포괄적인 RUM 전략의 필수적인 부분입니다.

7. 보안 고려 사항

성능 데이터를 수집하고 전송할 때 보안에 유의하십시오. 민감한 사용자 정보를 수집하지 말고 데이터가 안전하게 전송되도록(예: HTTPS 사용) 하십시오.

예제: Resource Timing API를 사용한 첫 바이트까지의 시간(TTFB) 측정

TTFB는 브라우저가 서버로부터 데이터의 첫 바이트를 수신하는 데 걸리는 시간입니다. `mark`와 `measure`로 정의된 엄격한 의미의 사용자 지정 메트릭은 아니지만, 가치 있는 성능 지표이며 Resource Timing API를 통해 접근하고 Performance Observer로 관찰할 수 있습니다.

            
const ttfbObserver = new PerformanceObserver((list) => {
  list.getEntriesByType('resource').forEach((entry) => {
    if (entry.name === window.location.href) { // Check if it's the main document
      const ttfb = entry.responseStart - entry.startTime;
      console.log(`TTFB: ${ttfb}ms`);
      // Send ttfb to your analytics platform
    }
  });
});

ttfbObserver.observe({ type: 'resource', buffered: true });

            

              
                Copy
              
            
          

크로스 브라우저 호환성

Performance Observer API는 최신 브라우저에서 널리 지원됩니다. 그러나 항상 브라우저 호환성을 확인하고 구형 브라우저를 위한 대체 메커니즘을 제공하는 것이 좋습니다. Performance Observer API를 지원하지 않는 브라우저를 위해 폴리필이나 더 간단한 측정 기술을 사용할 수 있습니다.

            
if ('PerformanceObserver' in window) {
  // Use Performance Observer API
  const observer = new PerformanceObserver((list) => { /* ... */ });
  observer.observe({ entryTypes: ['measure'] });
} else {
  // Use a fallback mechanism (e.g., Date.now() for simple time measurements)
  console.warn('PerformanceObserver API not supported in this browser.');
}

            

              
                Copy
              
            
          

사용자 지정 메트릭 사용을 위한 모범 사례

• 명확한 목표 정의: 어떤 특정 성능 측면을 모니터링하고 싶으신가요?
• 의미 있는 메트릭 이름 선택: 사용자 지정 메트릭에 대해 설명적이고 일관된 이름을 사용하세요.
• 메트릭 문서화: 각 사용자 지정 메트릭의 목적과 계산 방식을 명확하게 문서화하세요.
• 성능 예산 설정: 사용자 지정 메트릭에 대한 허용 가능한 성능 임계값을 정의하세요.
• 데이터 수집 및 분석 자동화: 빌드 프로세스 및 분석 파이프라인에 사용자 지정 메트릭 수집을 통합하세요.
• 정기적으로 메트릭 검토 및 개선: 애플리케이션이 발전함에 따라 성능 모니터링 요구 사항도 변경될 수 있습니다.

결론

프론트엔드 성능은 목적지가 아닌 지속적인 여정입니다. Frontend Performance Observer API를 활용하고 사용자 지정 메트릭을 정의함으로써 애플리케이션 성능에 대한 더 깊은 이해를 얻고 개선 영역을 식별할 수 있습니다. 이러한 맞춤형 성능 모니터링 접근 방식은 사용자 경험을 최적화하고 더 빠르고 반응성이 뛰어난 웹 애플리케이션을 제공할 수 있도록 힘을 실어줍니다. 위치나 장치에 관계없이 모든 사용자에게 애플리케이션이 최적으로 작동하도록 하려면 지속적으로 메트릭을 모니터링, 분석 및 개선하는 것을 잊지 마십시오.

이 글에서는 Performance Observer API를 사용한 사용자 지정 메트릭에 대한 포괄적인 개요를 제공했습니다. 이러한 기술을 특정 애플리케이션 요구에 맞게 조정하고, 성능 최적화에 대한 정보에 입각한 결정을 내리기 위해 데이터를 지속적으로 모니터링하고 분석하는 것이 중요합니다.

참고 자료:

• PerformanceObserver API - MDN 웹 문서
• performance.mark() - MDN 웹 문서
• performance.measure() - MDN 웹 문서